[00:10.070 --> 00:12.050]  Good morning, everyone.
[00:12.350 --> 00:17.430]  I am very honored to be able to be on the DevCon stage today.
[00:17.730 --> 00:20.050]  Maybe you can feel it.
[00:20.050 --> 00:23.410]  Just like when I first participated in DevCon many years ago,
[00:23.410 --> 00:27.290]  I felt that the style and culture of DevCon
[00:27.290 --> 00:29.690]  was very different from the academic meetings I used to attend,
[00:29.690 --> 00:32.850]  especially the academic meetings I attended in China.
[00:32.850 --> 00:37.650]  For example, there was no leadership instructions,
[00:37.650 --> 00:40.350]  and there was no academic support.
[00:41.770 --> 00:45.830]  So I mentioned in the opening video of DevCon
[00:45.830 --> 00:48.750]  that we really hope that DevCon
[00:48.750 --> 00:52.770]  can bring some new culture and ideas to China.
[00:53.370 --> 00:58.470]  You have also seen the translation next to it in the past two days.
[00:58.470 --> 01:00.690]  Of course, I did this translation myself.
[01:02.970 --> 01:05.830]  Our foreign speakers, their PPTs,
[01:05.830 --> 01:08.290]  are some of the volunteers I organized.
[01:08.290 --> 01:11.290]  Mainly some of our PhD students did some translation.
[01:11.290 --> 01:14.870]  One of the PhD students sent me his own feelings.
[01:14.870 --> 01:19.970]  I think at this point, we, DevCon China, have already done it.
[01:21.550 --> 01:22.830]  In the past few days,
[01:22.830 --> 01:25.990]  he has already experienced
[01:25.990 --> 01:28.310]  what it means to be a hacker
[01:28.310 --> 01:28.590]  in the process of communicating with foreign speakers.
[01:28.590 --> 01:34.110]  It is probably the curiosity and passion for technology,
[01:34.110 --> 01:36.630]  the yearning for freedom,
[01:36.630 --> 01:38.870]  and the pursuit of perfection.
[01:39.450 --> 01:40.670]  From this point of view,
[01:40.670 --> 01:43.550]  I think DevCon China has really achieved
[01:43.550 --> 01:46.890]  the integration of the hacker spirit and Chinese culture.
[01:47.990 --> 01:52.070]  Today, I mainly want to share with you
[01:52.070 --> 01:54.390]  some of the research we have done recently.
[01:56.270 --> 01:59.570]  From the outside, attacking the inside.
[01:59.570 --> 02:04.330]  Here, we mainly use the latest
[02:04.330 --> 02:08.130]  or already widely accepted standard
[02:08.130 --> 02:09.870]  It is called cross-domain,
[02:09.870 --> 02:13.310]  cross-domain resource sharing.
[02:13.450 --> 02:18.190]  The main work is done by my PhD student, Chen Jianjun.
[02:18.190 --> 02:22.790]  But in fact, there is also a cooperation from other units,
[02:22.790 --> 02:26.230]  including Jiang Jian from SIP Security,
[02:26.230 --> 02:28.430]  also a former student of mine,
[02:28.430 --> 02:30.990]  Dr. Wan Tao from Huawei Jiangda,
[02:30.990 --> 02:33.310]  Dr. Chen Shuo from Microsoft,
[02:33.310 --> 02:36.770]  Professor Warren Paxson from UC Berkeley,
[02:36.770 --> 02:38.130]  and Professor Yang Ming from Fudan University.
[02:38.450 --> 02:43.710]  Our work will be published in August this year.
[02:44.110 --> 02:46.230]  What is this specific work?
[02:46.270 --> 02:48.980]  Let's take a look at the current attack scene.
[02:50.380 --> 02:53.000]  The attackers' attacks on the internet
[02:54.520 --> 02:57.780]  are usually made by firewalls.
[02:57.880 --> 02:59.900]  Even a simple address conversion
[02:59.900 --> 03:02.900]  can make such an attack impossible.
[03:03.760 --> 03:06.820]  A very intuitive idea is
[03:06.820 --> 03:11.160]  whether it is possible to attack through the web.
[03:12.300 --> 03:16.060]  For example, right-wing users click on a website.
[03:16.060 --> 03:17.920]  This is a website attacked by hackers.
[03:17.920 --> 03:20.300]  Then through JavaScript,
[03:20.300 --> 03:24.260]  the attacker's script is loaded into the user's browser.
[03:24.260 --> 03:27.380]  Then the user's browser attacks the internet.
[03:32.410 --> 03:35.530]  Of course, if you are familiar with web security,
[03:35.530 --> 03:37.510]  you may be very clear.
[03:37.510 --> 03:42.030]  Now, browsers have restrictions on cross-border resource visits.
[03:42.250 --> 03:46.050]  The most common strategy is SOP,
[03:46.050 --> 03:48.190]  which stands for Same-Origin Policy.
[03:48.190 --> 03:53.810]  In the general sense of SOP,
[03:53.810 --> 04:00.010]  we can imagine that it restricts cross-border visits.
[04:00.010 --> 04:06.150]  At least you can't read resources from other sources.
[04:08.170 --> 04:12.730]  But just like safety, performance, and functionality,
[04:12.730 --> 04:15.630]  they are often a pair of contradictions.
[04:17.150 --> 04:22.990]  In many cases, developers still need cross-border visits.
[04:22.990 --> 04:26.070]  So there are all kinds of ways to get around.
[04:26.070 --> 04:30.090]  One of them is JSON-P, which is more common in recent years.
[04:30.090 --> 04:31.790]  You may have heard of it.
[04:31.790 --> 04:35.850]  JSON-P makes it very convenient for developers,
[04:35.850 --> 04:37.920]  but it also brings a lot of problems.
[04:38.330 --> 04:42.870]  In recent years, it has become a standard.
[04:42.870 --> 04:47.130]  For example, cross-border resource sharing.
[04:48.190 --> 04:53.270]  Now mainstream browsers have achieved this standard.
[04:53.270 --> 04:59.290]  And most mainstream websites already have this feature.
[05:00.010 --> 05:09.070]  You can say that cross-border is a feature that provides managers with cross-border visits.
[05:09.070 --> 05:15.310]  At the same time, it protects the security of resource sharing.
[05:16.010 --> 05:24.230]  But in recent research, we found that it is not as safe as it was originally designed.
[05:25.150 --> 05:32.310]  Because of the cross-border feature,
[05:32.310 --> 05:38.170]  you can access internal resources through the browser,
[05:38.170 --> 05:41.530]  including creating a new file,
[05:41.530 --> 05:45.570]  deleting some files in your file server,
[05:45.570 --> 05:49.690]  and even getting a share on the internal web server.
[05:51.810 --> 05:58.130]  In the past, there were some loopholes blocked by firewalls in the internal network.
[05:59.050 --> 06:01.150]  For example, there was a loophole in Strikes 2.
[06:01.150 --> 06:03.610]  Even if there is such a loophole in the internal network,
[06:03.610 --> 06:04.950]  the attacker can't get in.
[06:04.950 --> 06:07.150]  But now, with cross-border,
[06:07.150 --> 06:10.250]  such an attack may become a reality.
[06:13.870 --> 06:16.130]  I am a professor at Tsinghua University.
[06:17.050 --> 06:20.070]  As a professor, Jason Street just mentioned,
[06:21.290 --> 06:25.030]  I only gave one corner of the truth.
[06:25.030 --> 06:27.130]  The remaining three corners...
[06:27.130 --> 06:29.710]  Let's welcome my student, Chen Jianjun.
[06:29.710 --> 06:33.770]  Chen Jianjun is a Ph.D. student at Tsinghua University.
[06:35.390 --> 06:40.330]  He is my first Ph.D. student.
[06:40.570 --> 06:42.490]  He is about to graduate.
[06:42.490 --> 06:45.210]  His next step is to go to Berkeley for a Ph.D.
[06:46.070 --> 06:47.530]  He has already achieved a great success
[06:47.530 --> 06:51.670]  in the four top universities in the academic circle.
[06:53.530 --> 06:57.610]  Today, let's welcome Chen Jianjun to share with us
[06:57.610 --> 07:02.790]  the research on the cross-border attack on the internal network.
[07:03.130 --> 07:04.410]  Jianjun.
[07:10.520 --> 07:14.020]  It is a great honor to be here at DEVCON.
[07:14.220 --> 07:15.680]  I would like to share with you
[07:15.680 --> 07:19.740]  the article that is about to be published on User-Lead Security.
[07:20.400 --> 07:24.960]  I will talk about the details in four aspects.
[07:25.580 --> 07:29.860]  First, I will talk about the background of the web and cross-border.
[07:29.860 --> 07:33.020]  Then, I will talk about the security issues of the three cores.
[07:33.820 --> 07:37.240]  Then, I will talk about the security situation of the cores in a real website.
[07:39.140 --> 07:41.920]  Finally, I will talk about how to defend against such issues.
[07:42.160 --> 07:44.480]  First, let's look at the background of the web.
[07:44.980 --> 07:46.420]  Since we are talking about the security of the web,
[07:46.420 --> 07:48.560]  let's talk about the synchronization strategy.
[07:48.780 --> 07:51.060]  The synchronization strategy defines a circle.
[07:51.060 --> 07:52.320]  It is composed of three groups,
[07:52.640 --> 07:54.520]  which are the protocol, domain name and port.
[07:54.720 --> 07:56.360]  Generally speaking,
[07:56.360 --> 08:01.760]  the synchronization strategy is that it is isolated from two different circles.
[08:01.760 --> 08:04.980]  One circle cannot operate the data of another circle.
[08:04.980 --> 08:05.940]  It cannot cross-circle.
[08:06.900 --> 08:09.680]  For example, A.com cannot operate the data of B.com.
[08:10.340 --> 08:15.100]  However, this is just a misunderstanding of DOM.
[08:18.960 --> 08:21.500]  SOP has different restrictions on different network resources.
[08:21.500 --> 08:22.220]  Let's look at the details.
[08:22.220 --> 08:23.560]  For example, in this place,
[08:31.560 --> 08:35.680]  A.com wants to send a request to B.com
[08:35.680 --> 08:38.040]  and read the resource response of B.com.
[08:38.040 --> 08:40.720]  How will the synchronization strategy restrict it?
[08:41.240 --> 08:44.460]  It is not that it cannot be visited at all.
[08:44.620 --> 08:46.420]  It can be sent.
[08:46.420 --> 08:49.240]  A.com can send a request to B.com,
[08:49.240 --> 08:51.400]  but it cannot read the response.
[08:54.470 --> 08:55.290]  Why do I say it is a misunderstanding of DOM?
[08:55.290 --> 08:56.490]  It can be sent.
[08:58.020 --> 09:00.130]  For example, here is a simple example.
[09:00.130 --> 09:04.130]  A.com's HTML file is automatically submitted to B.com.
[09:04.430 --> 09:08.830]  It can also automatically click on the form request
[09:08.830 --> 09:13.490]  and send the request to B.com.
[09:13.490 --> 09:15.090]  This is a POST request.
[09:15.980 --> 09:18.010]  What kind of harm does this bring?
[09:18.450 --> 09:20.110]  It brings two harms.
[09:20.110 --> 09:21.830]  The first one is the attack of CSRF.
[09:22.830 --> 09:24.610]  As mentioned in the previous report,
[09:24.610 --> 09:27.210]  you used the login CSRF attack on my account.
[09:27.430 --> 09:29.610]  Let's talk about the principle of the CSRF attack.
[09:29.890 --> 09:34.210]  First, the victim logged into his own bank website
[09:34.210 --> 09:37.290]  and set a KUKA in the browser.
[09:38.970 --> 09:42.450]  Second, when he logged into the bank and operated the bank website,
[09:42.450 --> 09:44.970]  he wanted to check the information
[09:44.970 --> 09:47.450]  and accidentally visited the attacker's website.
[09:47.450 --> 09:49.230]  However, due to the restriction of the synchronization strategy,
[09:49.230 --> 09:52.510]  even if he visited the attacker's website,
[09:52.510 --> 09:54.250]  he couldn't read the information directly from the DOM.
[09:56.630 --> 09:58.330]  This is the restriction of the synchronization strategy.
[09:58.630 --> 10:00.890]  However, the request is not restricted by the synchronization strategy.
[10:02.050 --> 10:05.170]  The attacker can send a POST request to the bank website
[10:05.170 --> 10:05.990]  through his own website,
[10:05.990 --> 10:07.670]  through the browser operated by JavaScript.
[10:11.650 --> 10:15.370]  In this request, KUKA is used.
[10:15.370 --> 10:17.870]  KUKA will be automatically added to each request.
[10:17.870 --> 10:23.750]  In this way, the user's KUKA is included in the POST request.
[10:23.910 --> 10:31.330]  Then, when the KUKA verifies the origin of the request
[10:31.330 --> 10:31.430]  through the bank website,
[10:31.430 --> 10:35.160]  he thinks that the request was done by the victim himself.
[10:35.530 --> 10:37.250]  So he executed this operation
[10:37.250 --> 10:41.450]  and transferred the bill to the attacker's account.
[10:43.650 --> 10:47.770]  The second type of attack is the HTML form protocol attack.
[10:48.590 --> 10:53.090]  This attack means that
[10:53.090 --> 10:55.870]  the attacker can use the victim's browser
[10:55.870 --> 10:57.970]  to cross-protocol attack.
[10:57.970 --> 11:01.750]  For example, he wants to attack an SMTP server, an email server.
[11:03.130 --> 11:07.990]  First, the victim accidentally clicked a link, right?
[11:10.010 --> 11:12.490]  Then, the JavaScript in this link
[11:12.490 --> 11:15.110]  sends a POST request to the user's browser.
[11:15.930 --> 11:17.390]  In this POST request,
[11:17.390 --> 11:20.890]  the attacker can construct the body of the request
[11:20.890 --> 11:25.910]  to construct some SMTP commands in it.
[11:25.910 --> 11:27.410]  In this process,
[11:27.410 --> 11:30.790]  due to the strong tolerance of many services,
[11:30.790 --> 11:34.250]  he will ignore the unknown commands
[11:34.250 --> 11:37.710]  and execute the SMTP commands he knows in it.
[11:38.590 --> 11:43.090]  In this way, he can use the user's browser
[11:43.090 --> 11:46.590]  to send an email to the email server.
[11:49.450 --> 11:52.150]  Maybe this email server is in the user's network
[11:52.150 --> 11:55.770]  and can cross-network and cross-protocol attack.
[12:00.020 --> 12:01.240]  As we mentioned earlier,
[12:03.480 --> 12:04.720]  SOP has two parts.
[12:04.720 --> 12:06.000]  One is cross-development.
[12:06.080 --> 12:09.460]  It can be allowed to send, but it can't be read.
[12:09.500 --> 12:10.220]  It can be allowed to send,
[12:10.220 --> 12:12.820]  but the harm is the attack of CSF, HFPA.
[12:14.360 --> 12:16.120]  But it can't be read.
[12:16.120 --> 12:17.740]  This affects the web
[12:18.440 --> 12:20.940]  and limits the development of the web.
[12:21.060 --> 12:22.920]  Many times, the web needs a language
[12:22.920 --> 12:24.520]  to read other languages.
[12:24.520 --> 12:26.520]  For example, an e-commerce website
[12:27.780 --> 12:31.660]  may want to read a package information of a courier company
[12:31.660 --> 12:35.220]  and then track a package on its own website.
[12:35.320 --> 12:38.220]  How does this function work?
[12:38.220 --> 12:41.440]  It needs a cross-source reading information.
[12:43.740 --> 12:46.540]  In order to achieve this cross-source reading,
[12:46.540 --> 12:47.600]  but SOP doesn't allow it,
[12:48.620 --> 12:51.800]  the developers came up with some ad-hoc solutions.
[12:52.820 --> 12:56.780]  The JSONP solution was first proposed in 2005.
[12:58.560 --> 13:01.060]  This solution is very dangerous.
[13:04.020 --> 13:06.360]  JSONP brings a series of security issues.
[13:06.360 --> 13:08.700]  The most prominent security issue is that
[13:08.700 --> 13:11.380]  JSONP itself does not have an anti-counterfeiting mechanism.
[13:11.380 --> 13:14.460]  It can't say which website I want to visit
[13:14.460 --> 13:15.960]  and which website I don't want to visit.
[13:16.000 --> 13:17.800]  In order to solve this problem,
[13:17.800 --> 13:20.660]  the JSONP solution came up with CORS.
[13:22.040 --> 13:26.840]  In Chinese, CORS stands for cross-source sharing.
[13:27.180 --> 13:30.640]  It is an anti-counterfeiting mechanism that shows authorization.
[13:35.840 --> 13:39.060]  Its principle is to generate an anti-counterfeiting strategy
[13:39.060 --> 13:41.440]  to limit the scope of SOP.
[13:43.520 --> 13:46.300]  In 2009, this protocol was supported by all browsers.
[13:46.620 --> 13:49.260]  In 2014, it became W3C's standard.
[13:49.260 --> 13:51.060]  This is how the protocol works.
[13:51.500 --> 13:52.580]  It is quite simple.
[13:52.580 --> 13:54.480]  It is divided into three steps.
[13:55.120 --> 14:00.340]  For example, now the browser has loaded a Javascript from A.com.
[14:00.340 --> 14:02.480]  After that, Javascript will issue a cross-source request.
[14:02.480 --> 14:04.040]  For example, I want to issue a cross-source request to B.com.
[14:04.040 --> 14:06.680]  During this process,
[14:06.680 --> 14:12.220]  the browser will add an origin header to the request
[14:13.820 --> 14:17.320]  to mark that the source code is from A.com.
[14:17.940 --> 14:22.800]  Then the server will generate an anti-counterfeiting strategy
[14:22.800 --> 14:22.840]  based on the request's origin,
[14:22.840 --> 14:24.900]  which is called access-control-alone-origin,
[14:24.900 --> 14:25.720]  and put it in the corresponding header
[14:25.720 --> 14:29.080]  to show that I am allowed to visit A.com.
[14:29.720 --> 14:33.940]  After the browser sees the corresponding header,
[14:33.940 --> 14:35.780]  it will compare the origin of the request
[14:35.780 --> 14:38.380]  to see if the corresponding strategy is consistent.
[14:38.380 --> 14:39.360]  If it is consistent,
[14:39.360 --> 14:40.980]  it will allow the Javascript to be read.
[14:40.980 --> 14:42.340]  If it is inconsistent,
[14:42.340 --> 14:44.260]  it will not allow the Javascript to be read.
[14:44.440 --> 14:45.720]  The principle is very simple.
[14:45.720 --> 14:47.560]  It is divided into three steps.
[14:48.960 --> 14:53.640]  But Quartz also provides some more detailed control,
[14:55.840 --> 15:01.260]  including method, header, and credentials.
[15:02.860 --> 15:04.740]  Including cookies and the like.
[15:07.620 --> 15:09.880]  For example, here is a simple example.
[15:09.880 --> 15:14.200]  When XHR sends a request,
[15:14.200 --> 15:18.040]  it allows the user to customize the method,
[15:18.040 --> 15:20.000]  customize the header,
[15:20.000 --> 15:22.680]  and customize whether to bring a cookie.
[15:22.740 --> 15:24.060]  But what is the problem with this?
[15:24.060 --> 15:25.900]  It is too flexible.
[15:25.960 --> 15:27.360]  It is too flexible for the web.
[15:27.360 --> 15:31.360]  It may damage some applications' CSR defense.
[15:31.360 --> 15:35.860]  Some applications rely on the customized header to do CSR defense.
[15:35.880 --> 15:38.440]  So Quartz divides the request into two categories.
[15:38.460 --> 15:39.600]  One is a simple request,
[15:39.600 --> 15:41.080]  and the other is a non-simple request.
[15:41.080 --> 15:43.100]  A simple request can be sent directly.
[15:43.720 --> 15:45.280]  Just like the previous process,
[15:45.280 --> 15:46.220]  the request can be sent directly.
[15:46.220 --> 15:47.240]  It is not harmful to the server.
[15:47.240 --> 15:48.280]  I will go directly to the request,
[15:48.280 --> 15:50.260]  and then you return me the visit policy.
[15:50.980 --> 15:53.700]  But a non-simple request is not safe.
[15:53.700 --> 15:55.200]  It cannot be sent directly.
[15:55.200 --> 15:58.480]  It requires an additional verification operation.
[15:59.540 --> 16:01.980]  How to judge whether a request is simple or not?
[16:02.000 --> 16:03.340]  There are three conditions.
[16:03.340 --> 16:05.540]  These three conditions look complicated.
[16:05.700 --> 16:07.080]  The principle is simple.
[16:07.080 --> 16:08.720]  It is the white list mechanism.
[16:09.020 --> 16:11.860]  The request header must be in the white list.
[16:12.140 --> 16:13.900]  The request method must be in the white list.
[16:14.040 --> 16:16.740]  The content type value must also be in the white list.
[16:19.160 --> 16:20.860]  What if it is a non-simple request?
[16:20.860 --> 16:21.980]  How to do it?
[16:22.420 --> 16:24.100]  Since the request cannot be sent directly,
[16:24.100 --> 16:27.760]  I will send a preflight request first.
[16:27.760 --> 16:29.760]  This request is safe.
[16:30.180 --> 16:34.400]  There is no user-created header.
[16:34.400 --> 16:37.240]  It is a header built in the browser.
[16:37.500 --> 16:41.860]  It tells the server that I am going to send this request later.
[16:41.860 --> 16:42.820]  There is a dangerous request.
[16:42.820 --> 16:43.920]  Will you let me send it?
[16:44.020 --> 16:46.080]  Then the server says you can send it.
[16:46.080 --> 16:48.220]  Then it checks whether this strategy is allowed to be sent.
[16:48.780 --> 16:51.140]  Then it performs this real operation.
[16:51.140 --> 16:53.680]  It is equivalent to adding a part of the request process.
[16:53.680 --> 16:54.400]  It is divided into two parts.
[16:54.400 --> 16:55.180]  One is preflight.
[16:55.180 --> 16:58.200]  The other is a real interview.
[17:03.060 --> 17:04.880]  What kind of problems may arise with such a cross mechanism?
[17:05.980 --> 17:08.960]  Here we found three problems.
[17:09.240 --> 17:13.220]  The first is that it is too relaxed to send the front end.
[17:13.320 --> 17:15.280]  It may cause security issues.
[17:19.020 --> 17:22.360]  Just now we talked about the request to automatically submit a post.
[17:22.360 --> 17:24.700]  It has caused a huge security threat to the current web.
[17:24.700 --> 17:27.980]  Such as the attack of CSF and HLPA.
[17:31.300 --> 17:36.400]  But when CORS designed the XHR interface,
[17:36.400 --> 17:41.160]  it is hidden and relaxed the forwarding front end.
[17:41.400 --> 17:44.840]  It can give the attacker a more flexible front end
[17:44.840 --> 17:46.780]  and bring some new security issues.
[17:46.780 --> 17:52.120]  We found that using this new security front end
[17:52.120 --> 17:54.180]  can bring four types of attacks.
[17:54.920 --> 17:57.000]  The first type of attack is that
[17:57.000 --> 18:01.400]  it can attack the second-level protocol services of the internal network
[18:01.400 --> 18:04.960]  to create and delete the internal network files.
[18:05.060 --> 18:08.100]  It can also attack the code execution loopholes of the internal network
[18:08.960 --> 18:11.300]  to get the files of the internal network server.
[18:11.300 --> 18:15.920]  It can also attack the CSF loopholes that could not be used before.
[18:15.920 --> 18:22.340]  It can even speculate the privacy information of any website.
[18:22.340 --> 18:26.740]  These loopholes are not only the loopholes of the service end,
[18:26.740 --> 18:28.080]  but also the loopholes of the browser.
[18:28.260 --> 18:30.340]  So in March, we have...
[18:34.280 --> 18:36.460]  In March, we have...
[18:36.460 --> 18:38.640]  I can't synchronize.
[18:38.640 --> 18:43.720]  In March, we have reported the loopholes to the browser manufacturers.
[18:45.580 --> 18:49.680]  But the browser manufacturers haven't fixed it yet.
[18:49.940 --> 18:53.740]  We reported it to Chrome, Firefox, Safari, Edge and IE.
[18:54.000 --> 19:00.740]  The main problem is that it may bring some destructive effects to the current web.
[19:00.900 --> 19:03.400]  If it needs to be fixed, it may have side effects.
[19:03.400 --> 19:05.440]  So it is difficult for them to fix it.
[19:05.440 --> 19:10.020]  They ask us not to reveal the details of the loopholes on DiverCon China
[19:11.380 --> 19:15.580]  to check if our PPT is safe.
[19:16.240 --> 19:18.120]  So they attach great importance to this issue.
[19:18.120 --> 19:19.760]  We also agree with their advice.
[19:19.760 --> 19:23.660]  But what we can do now can't let you down.
[19:23.660 --> 19:26.960]  So let's play a video.
[19:28.520 --> 19:32.120]  Please let the staff play the video.
[19:32.220 --> 19:34.360]  On the left is a browser.
[19:34.360 --> 19:38.000]  On the right is a remote attacker.
[19:38.000 --> 19:40.380]  The user on the left refreshes the browser.
[19:40.600 --> 19:46.580]  The attacker on the right gets the server.
[19:50.870 --> 19:53.750]  This is the attack effect.
[19:58.230 --> 20:05.210]  Now let's talk about the key points of today's talk.
[20:06.270 --> 20:08.590]  The first one is the risk of trust.
[20:08.670 --> 20:12.130]  The safety issue caused by the risk of trust.
[20:16.920 --> 20:22.520]  The core function of the course requires a user to trust another user to share the data.
[20:22.520 --> 20:27.500]  Of course, this kind of trust may increase the risk of attack.
[20:28.300 --> 20:30.600]  A website may not have a security loop.
[20:30.600 --> 20:32.380]  But it has a security loop in the trust area.
[20:32.380 --> 20:36.020]  In this way, the attacker can use the security loop in the trust area
[20:36.940 --> 20:41.420]  to attack the security loop in the trust area indirectly.
[20:42.620 --> 20:47.380]  Here we find that there are two types of risk of trust.
[20:49.220 --> 20:52.940]  The first type is the HTTPS trust HTTP.
[20:55.820 --> 21:00.860]  HTTPS can provide confidential and complete protection for the network communication.
[21:00.860 --> 21:03.060]  Even if the network is not safe,
[21:03.060 --> 21:08.520]  it can ensure that the middleman in the network cannot read the data in it.
[21:09.100 --> 21:16.380]  But if an HTTPS website trusts an HTTP website,
[21:17.580 --> 21:21.280]  the attacker can first hijack the HTTP website.
[21:21.280 --> 21:23.660]  Then through the HTTP website,
[21:23.660 --> 21:26.540]  send a request to read the resources of the HTTPS website.
[21:27.360 --> 21:30.520]  Here is a diagram of the process.
[21:31.740 --> 21:34.360]  When the victim visits another website,
[21:34.360 --> 21:35.760]  the attacker enters an iframe
[21:35.760 --> 21:40.680]  and forces the victim to visit the HTTP example.com.
[21:43.200 --> 21:46.620]  Then the attacker hijacks the HTTP example.com
[21:47.280 --> 21:49.600]  and enters some malicious JavaScript.
[21:51.280 --> 21:57.520]  Then the JavaScript sends the request to the HTTPS server.
[21:59.440 --> 22:03.140]  The HTTPS server is obviously from the HTTP example.com.
[22:03.140 --> 22:04.620]  I trust it.
[22:04.940 --> 22:07.340]  It returns the resources.
[22:08.600 --> 22:12.240]  Then the attacker's JavaScript gets the content.
[22:13.000 --> 22:16.460]  Then it can send the content to the attacker.
[22:16.460 --> 22:22.960]  This is the effect of the middleman hijacking the HTTPS website.
[22:24.580 --> 22:26.500]  The second type of reliance,
[22:26.500 --> 22:27.920]  which is risky,
[22:27.920 --> 22:29.580]  is the reliance on other fields.
[22:29.600 --> 22:33.300]  For example, the reliance on all subsidiary fields.
[22:35.000 --> 22:36.520]  The danger of this
[22:36.520 --> 22:38.440]  is that a subsidiary field's CSS
[22:38.440 --> 22:42.580]  may affect the security of the main field.
[22:43.280 --> 22:45.500]  For example, we found a case here.
[22:45.500 --> 22:47.320]  This is mail.riu.
[22:48.520 --> 22:49.340]  Its main field
[22:49.340 --> 22:54.160]  has a very strong security defense.
[22:54.160 --> 22:55.720]  It deploys CSP,
[22:56.080 --> 22:56.960]  HTTP Owing,
[22:56.960 --> 22:57.280]  Cookie,
[22:57.280 --> 22:58.420]  to prevent this CSS
[22:58.420 --> 23:00.620]  and provide a loophole reward.
[23:01.380 --> 23:04.140]  But its subsidiary field does not deploy CSP
[23:05.000 --> 23:06.520]  and does not provide a loophole reward.
[23:06.520 --> 23:08.440]  So it is very easy to find a subsidiary field's CSS.
[23:08.920 --> 23:10.900]  But its main field trusts all subsidiary fields.
[23:10.900 --> 23:11.280]  So we
[23:13.960 --> 23:15.280]  found such a loophole
[23:15.280 --> 23:17.760]  to use this subsidiary field's CSS
[23:17.760 --> 23:20.060]  to read sensitive information on the main field.
[23:22.160 --> 23:25.660]  The second one is that it trusts the third party's domain.
[23:25.660 --> 23:26.920]  It may bring a security risk.
[23:26.920 --> 23:28.000]  As I just said,
[23:28.000 --> 23:29.580]  even if your domain is safe,
[23:29.580 --> 23:32.680]  it cannot guarantee that your information is not leaked.
[23:32.680 --> 23:34.400]  Because you may have a security problem
[23:34.400 --> 23:36.000]  with the third party's reliance.
[23:36.740 --> 23:38.840]  We found a case here.
[23:39.200 --> 23:40.840]  A Korean e-commerce website
[23:40.840 --> 23:42.660]  has expired its trusted domain name.
[23:43.320 --> 23:45.920]  The attacker can register the expired domain name
[23:48.200 --> 23:49.940]  to carry out the attack.
[23:52.720 --> 23:56.840]  The third problem is the complexity of the course strategy.
[23:57.700 --> 24:00.240]  We found that four types of course strategies
[24:00.240 --> 24:02.520]  are prone to misconfiguration.
[24:04.940 --> 24:07.220]  We know that the core of the course
[24:07.220 --> 24:09.500]  is to generate a network control strategy at the service end
[24:09.500 --> 24:13.300]  to guide the browser to expand the SOP limit
[24:15.300 --> 24:16.980]  and achieve cross-domain sharing.
[24:16.980 --> 24:20.420]  But if the course strategy is wrong
[24:20.420 --> 24:21.860]  and the generation is wrong,
[24:21.860 --> 24:25.020]  it may lead to the trust of an attacker
[24:25.020 --> 24:27.880]  to achieve the SOP bypass.
[24:30.020 --> 24:32.280]  As for the misconfiguration of the course,
[24:32.280 --> 24:36.060]  there have been a lot of research by researchers.
[24:36.060 --> 24:37.560]  Here we summarize the previous research
[24:37.560 --> 24:41.960]  and find some new cases of misconfiguration.
[24:44.020 --> 24:46.080]  Let's watch a video
[24:46.080 --> 24:49.120]  on how to bypass the SOP limit
[24:49.120 --> 24:54.300]  to read the information on the SOHU video website.
[24:55.920 --> 24:57.860]  This loophole has been broken.
[24:59.240 --> 25:01.020]  So it has been fixed.
[25:01.020 --> 25:03.520]  Let's look at the SOHU video.
[25:03.520 --> 25:04.960]  This is a website of Alex Top,
[25:06.040 --> 25:09.540]  ranked 5th in China and 14th in the world.
[25:14.590 --> 25:16.770]  We can see that there is only one acquisition address in the acquisition address.
[25:16.770 --> 25:17.210]  Right?
[25:17.570 --> 25:18.590]  Only one acquisition address.
[25:18.970 --> 25:24.850]  Then let's visit the attacker's evildoing.com.
[25:24.850 --> 25:27.630]  We find that it has become two acquisition addresses
[25:27.630 --> 25:29.050]  and can read the user's information.
[25:29.050 --> 25:32.490]  Let's see if it has become two user addresses.
[25:32.490 --> 25:35.830]  We find that it can not only read the user's information
[25:35.830 --> 25:38.350]  but also write information to the user's account.
[25:39.810 --> 25:41.710]  So this is a very serious hazard.
[25:41.730 --> 25:45.350]  Let's see why there is a misconfiguration of the course strategy.
[25:45.350 --> 25:46.770]  What may happen?
[25:47.930 --> 25:50.190]  First of all, the strategy of the course is
[25:51.470 --> 25:53.470]  that the access control alone origin
[25:53.470 --> 25:55.150]  allows the configuration of the value.
[25:55.470 --> 25:56.990]  There are two standards for the course.
[25:56.990 --> 25:58.230]  One is the W3C standard,
[25:58.230 --> 26:00.130]  and the other is the WG standard.
[26:00.130 --> 26:01.670]  The WG standard is a standard
[26:01.670 --> 26:04.470]  launched by several browser manufacturers.
[26:04.810 --> 26:06.630]  In the W3C standard,
[26:06.630 --> 26:10.190]  the access control alone origin can be an origin list,
[26:10.190 --> 26:11.850]  or a NOR, or a signal.
[26:11.850 --> 26:14.450]  But in the WG standard,
[26:14.450 --> 26:16.870]  it can only be a single origin,
[26:16.870 --> 26:18.390]  or a NOR, or a signal.
[26:20.090 --> 26:22.190]  And in all the browsers,
[26:22.190 --> 26:23.030]  all the browsers we tested
[26:23.030 --> 26:25.310]  followed the WG standard.
[26:25.310 --> 26:26.510]  That is to say,
[26:26.510 --> 26:29.310]  only such a configuration,
[26:29.470 --> 26:31.250]  a green configuration, is legal.
[26:31.390 --> 26:33.010]  And the other two configurations
[26:33.010 --> 26:34.990]  are all wrong.
[26:37.850 --> 26:38.830]  We found that
[26:38.830 --> 26:41.210]  many websites did not notice this.
[26:42.110 --> 26:43.230]  The issue of the origin configuration
[26:45.310 --> 26:47.690]  actually includes some large websites
[26:47.690 --> 26:48.870]  with the origin configuration.
[26:49.570 --> 26:51.170]  And although this configuration
[26:51.170 --> 26:52.250]  cannot cause security issues,
[26:52.250 --> 26:54.090]  it is indeed a misconfiguration.
[26:58.760 --> 26:59.280]  Uh...
[27:00.740 --> 27:02.980]  So, if a website
[27:02.980 --> 27:06.220]  wants to share data to multiple regions,
[27:06.220 --> 27:07.120]  what should it do?
[27:08.440 --> 27:09.920]  I just want to be able to
[27:09.920 --> 27:11.660]  share data to A.com and B.com at the same time.
[27:11.660 --> 27:13.480]  Then we must have a dynamic
[27:13.480 --> 27:15.380]  access control strategy.
[27:17.060 --> 27:19.020]  In this dynamic process,
[27:19.020 --> 27:20.320]  we found that in fact,
[27:20.320 --> 27:21.760]  security issues are very easy to occur.
[27:22.360 --> 27:24.480]  We have four types of security issues.
[27:24.560 --> 27:25.560]  The first type of security issue
[27:25.560 --> 27:26.340]  is...
[27:26.340 --> 27:28.280]  We have five types of security issues.
[27:28.280 --> 27:29.860]  The first type of security issue is...
[27:29.860 --> 27:30.800]  Many websites
[27:30.800 --> 27:31.620]  when configuring this
[27:31.620 --> 27:33.740]  configuration strategy,
[27:33.740 --> 27:35.800]  there is an example here,
[27:35.800 --> 27:37.340]  which is a configuration of NGX.
[27:37.380 --> 27:39.520]  Directly add this
[27:39.520 --> 27:40.760]  access control
[27:40.760 --> 27:41.700]  to this NGX.
[27:41.700 --> 27:42.800]  Alone origin,
[27:42.800 --> 27:43.960]  ATP origin.
[27:45.620 --> 27:46.540]  It is equivalent to
[27:46.540 --> 27:48.200]  reflection of any origin header.
[27:48.200 --> 27:48.920]  This can achieve
[27:48.920 --> 27:49.720]  the effect of functionality.
[27:49.720 --> 27:50.560]  However,
[27:51.840 --> 27:52.740]  the harm is that
[27:52.740 --> 27:54.300]  it trusts any language.
[27:54.300 --> 27:55.240]  It is equivalent to
[27:55.240 --> 27:57.060]  the SOP of the browser.
[27:57.060 --> 27:58.040]  It completely fails.
[27:58.520 --> 28:00.740]  Any language can be read directly.
[28:02.700 --> 28:03.580]  This configuration
[28:03.580 --> 28:04.380]  is also the highest
[28:04.380 --> 28:06.260]  in our discovery.
[28:06.260 --> 28:08.700]  is also the highest
[28:08.700 --> 28:08.860]  in our discovery.
[28:08.860 --> 28:10.640]  In 2016,
[28:10.640 --> 28:11.240]  someone did
[28:12.440 --> 28:13.660]  for X-top 1 million.
[28:13.660 --> 28:14.320]  a statistic for X-top 1 million.
[28:14.320 --> 28:14.920]  The result of the measurement
[28:14.920 --> 28:15.880]  is that there is a problem
[28:15.880 --> 28:16.520]  in each of the 10 websites
[28:16.520 --> 28:17.640]  that configure the course.
[28:17.640 --> 28:18.240]  that configure the course.
[28:19.380 --> 28:20.620]  And in our recent
[28:20.620 --> 28:21.600]  measurement,
[28:21.960 --> 28:24.380]  there is a configuration
[28:24.380 --> 28:25.100]  that comes out
[28:25.100 --> 28:26.540]  with this problem.
[28:26.920 --> 28:28.000]  Although this configuration
[28:28.000 --> 28:30.760]  does not look obvious,
[28:30.760 --> 28:31.480]  but in fact,
[28:31.480 --> 28:32.440]  it is very harmful
[28:32.440 --> 28:33.320]  and it is very easy
[28:33.320 --> 28:34.400]  to have this problem.
[28:38.610 --> 28:39.130]  The problem with
[28:39.130 --> 28:40.410]  the previous configuration
[28:40.410 --> 28:41.650]  is that
[28:41.650 --> 28:43.270]  it does not do any training.
[28:43.290 --> 28:44.410]  What is the origin header?
[28:44.410 --> 28:45.710]  What is the origin header
[28:45.710 --> 28:46.230]  I allow?
[28:46.330 --> 28:46.710]  Then
[28:47.730 --> 28:49.130]  there is a more advanced
[28:49.130 --> 28:50.250]  error method,
[28:50.250 --> 28:50.910]  that is,
[28:51.530 --> 28:53.290]  I take a look at this origin header
[28:53.290 --> 28:53.890]  I take a look at this origin header
[28:53.890 --> 28:55.970]  whether it is the origin header
[28:55.970 --> 28:56.310]  I want.
[28:56.310 --> 28:56.510]  whether it is the origin header
[28:56.510 --> 28:56.590]  For example,
[28:56.590 --> 28:57.110]  here is a configuration
[28:57.110 --> 28:58.190]  of NGX.
[28:59.170 --> 29:00.310]  Is this configuration
[29:00.310 --> 29:01.890]  safe?
[29:04.570 --> 29:05.490]  This is
[29:06.350 --> 29:08.190]  obviously not safe for us.
[29:08.610 --> 29:09.250]  It is that
[29:09.690 --> 29:11.290]  there is a lack of
[29:11.290 --> 29:11.990]  an end service
[29:11.990 --> 29:12.670]  at the last place.
[29:13.070 --> 29:13.990]  Then the attacker
[29:13.990 --> 29:17.110]  can add a
[29:17.110 --> 29:17.450]  .evil.com
[29:17.450 --> 29:18.930]  .evil.com
[29:18.930 --> 29:19.190]  to realize
[29:19.190 --> 29:20.790]  the bypassing strategy.
[29:20.790 --> 29:21.290]  The example
[29:21.290 --> 29:22.210]  we just demonstrated
[29:22.210 --> 29:23.530]  in the video
[29:23.530 --> 29:23.790]  is the example
[29:23.790 --> 29:25.050]  of the search video
[29:25.050 --> 29:25.370]  that made this mistake.
[29:28.330 --> 29:29.170]  The search video
[29:29.170 --> 29:30.630]  we put this loophole
[29:30.630 --> 29:32.150]  because the search itself
[29:32.150 --> 29:32.890]  does not have a
[29:32.890 --> 29:33.730]  safe response center
[29:33.730 --> 29:34.350]  we reported this loophole
[29:34.350 --> 29:34.870]  to them through
[29:34.870 --> 29:37.230]  freebuff.
[29:37.230 --> 29:37.950]  But they fixed
[29:37.950 --> 29:38.070]  this problem
[29:38.070 --> 29:39.910]  but did not fix it well.
[29:39.910 --> 29:40.050]  What is the reason
[29:40.050 --> 29:42.030]  for not fixing it well?
[29:42.030 --> 29:43.370]  The first error
[29:43.370 --> 29:43.770]  avoidance
[29:43.770 --> 29:44.790]  jumped into the second
[29:46.910 --> 29:49.510]  error pit.
[29:49.510 --> 29:51.190]  What is the second error pit?
[29:51.190 --> 29:51.910]  I can't see
[29:51.910 --> 29:55.050]  its misconfiguration.
[29:55.050 --> 29:56.790]  This is me
[29:56.790 --> 29:57.070]  on stackoverflow
[29:57.070 --> 29:57.210]  to see
[29:54.950 --> 29:55.950]  a configuration method
[29:55.950 --> 29:56.950]  recommended by others.
[29:58.990 --> 30:00.170]  I see this
[30:00.170 --> 30:01.030]  because the previous configuration
[30:01.030 --> 30:01.290]  said
[30:01.950 --> 30:02.890]  you do not have
[30:02.890 --> 30:03.990]  the example.com
[30:03.990 --> 30:05.250]  there is a security issue.
[30:05.250 --> 30:05.850]  Then I will check
[30:05.850 --> 30:06.350]  whether you are
[30:06.350 --> 30:06.570]  at the end of
[30:06.570 --> 30:07.310]  the example.com
[30:08.510 --> 30:09.550]  right?
[30:10.890 --> 30:12.090]  But this is also
[30:12.090 --> 30:12.630]  problematic.
[30:12.630 --> 30:14.010]  What may be the problem?
[30:15.930 --> 30:16.910]  The attacker can
[30:16.910 --> 30:18.090]  send such a
[30:18.090 --> 30:19.210]  attack example.com
[30:19.910 --> 30:20.310]  It is also
[30:20.310 --> 30:20.530]  at the end of
[30:20.530 --> 30:21.530]  the example.com
[30:21.530 --> 30:22.830]  But this domain
[30:22.830 --> 30:23.350]  can be registered
[30:24.010 --> 30:25.390]  by the attacker.
[30:26.810 --> 30:27.970]  So it is also
[30:27.970 --> 30:28.650]  not safe.
[30:30.110 --> 30:30.810]  We also reported
[30:30.810 --> 30:31.530]  this error pit
[30:31.530 --> 30:34.290]  to him.
[30:37.410 --> 30:38.050]  I haven't seen
[30:38.050 --> 30:39.690]  if it has been fixed.
[30:39.710 --> 30:40.150]  It was reported
[30:40.470 --> 30:41.530]  a few days ago.
[30:46.510 --> 30:46.830]  Then
[30:46.830 --> 30:47.270]  this
[30:48.170 --> 30:48.870]  did not transfer
[30:49.390 --> 30:50.510]  the last two types
[30:50.510 --> 30:51.630]  did not transfer
[30:51.630 --> 30:52.550]  this
[30:54.730 --> 30:55.890]  point.
[30:55.890 --> 30:56.790]  Many websites
[30:56.790 --> 30:57.870]  will check
[30:57.870 --> 30:58.030]  when they
[30:58.030 --> 30:58.090]  hold the
[30:58.090 --> 30:58.330]  origin
[30:59.510 --> 31:00.470]  they will
[31:01.010 --> 31:01.610]  use the
[31:01.610 --> 31:01.930]  positive expression
[31:01.930 --> 31:03.110]  to check.
[31:04.130 --> 31:04.690]  When they
[31:04.690 --> 31:05.230]  write the positive expression
[31:05.230 --> 31:05.930]  they did not
[31:05.930 --> 31:07.070]  transfer this point.
[31:07.890 --> 31:08.670]  This causes
[31:08.670 --> 31:09.150]  this point
[31:09.150 --> 31:09.530]  to be replaced
[31:09.530 --> 31:10.510]  by any alphabet.
[31:12.570 --> 31:13.370]  Because in the
[31:13.370 --> 31:13.650]  positive expression
[31:14.390 --> 31:14.630]  a point
[31:14.630 --> 31:15.770]  is a
[31:15.770 --> 31:17.750]  common match.
[31:17.750 --> 31:18.350]  So it can
[31:19.070 --> 31:19.230]  cause
[31:19.230 --> 31:20.250]  a security issue.
[31:20.250 --> 31:20.770]  We also found
[31:20.770 --> 31:23.190]  that there are websites
[31:23.190 --> 31:23.570]  that even
[31:23.570 --> 31:25.870]  have purple-wearing matching.
[31:25.870 --> 31:26.870]  We found
[31:25.870 --> 31:26.450]  that as long as
[31:26.450 --> 31:26.790]  the host
[31:26.790 --> 31:28.170]  from the
[31:28.170 --> 31:28.450]  origin
[31:30.310 --> 31:30.790]  is
[31:31.530 --> 31:31.930]  a self-proclaimed
[31:31.930 --> 31:32.430]  purple-wearing
[31:32.430 --> 31:32.670]  host,
[31:32.670 --> 31:33.670]  it is allowed.
[31:38.730 --> 31:39.570]  We talked about
[31:39.570 --> 31:39.910]  the five types
[31:39.910 --> 31:39.930]  of
[31:39.930 --> 31:40.170]  matching
[31:40.170 --> 31:41.110]  earlier.
[31:47.070 --> 31:47.550]  Then
[31:47.550 --> 31:48.030]  we will
[31:48.730 --> 31:49.690]  look at
[31:49.690 --> 31:50.550]  the second
[31:50.550 --> 31:50.790]  category
[31:50.790 --> 31:50.870]  of
[31:50.870 --> 31:51.290]  questions.
[31:51.290 --> 31:51.690]  The first one
[31:51.690 --> 31:52.850]  is the
[31:52.850 --> 31:53.510]  x-control
[31:53.510 --> 31:53.530]  we just
[31:53.530 --> 31:53.610]  talked about.
[31:53.610 --> 31:53.750]  There can
[31:53.750 --> 31:54.450]  be three
[31:54.450 --> 31:59.090]  types of
[31:59.090 --> 31:59.550]  questions
[32:00.090 --> 32:00.590]  in
[32:02.970 --> 32:03.910]  The
[32:03.910 --> 32:04.230]  first
[32:04.230 --> 32:05.250]  one is
[32:05.250 --> 32:05.470]  in
[32:08.810 --> 32:09.280]  RFC
[32:10.490 --> 32:11.430]  6454
[32:11.430 --> 32:12.230]  where
[32:12.230 --> 32:12.590]  it is
[32:12.590 --> 32:12.830]  defined as
[32:12.830 --> 32:14.790]  if a
[32:14.790 --> 32:15.260]  language
[32:16.010 --> 32:17.130]  comes from
[32:17.130 --> 32:17.830]  a
[32:17.830 --> 32:18.570]  private
[32:18.570 --> 32:19.270]  domain,
[32:19.270 --> 32:20.090]  then
[32:20.730 --> 32:21.190]  the
[32:21.190 --> 32:21.670]  query
[32:21.670 --> 32:21.990]  origin
[32:21.990 --> 32:22.830]  cannot
[32:22.830 --> 32:23.330]  directly
[32:23.330 --> 32:23.610]  show
[32:23.610 --> 32:23.690]  the
[32:27.090 --> 32:28.090]  domain.
[32:23.690 --> 32:26.250]  I will set it to this one.
[32:26.770 --> 32:32.810]  But it didn't define what is a private sensitive domain.
[32:33.230 --> 32:35.350]  Local documents are considered a private sensitive domain.
[32:35.350 --> 32:36.450]  Is there anything else?
[32:38.150 --> 32:42.610]  So when many websites are doing this hyper app,
[32:42.610 --> 32:44.690]  that is, when mixing apps,
[32:47.350 --> 32:48.690]  it allows this...
[32:48.690 --> 32:53.830]  Because the hyper app needs this ATM25 to do the interface.
[32:54.670 --> 32:56.270]  It will allow this...
[32:56.270 --> 32:59.250]  JavaScript will send a request directly from the local file.
[32:59.250 --> 33:00.870]  The output is a lore.
[33:01.770 --> 33:04.470]  It allows this lore to read.
[33:04.470 --> 33:05.290]  But it brings...
[33:05.290 --> 33:07.530]  We found that in the actual browser,
[33:07.530 --> 33:10.890]  this lore can be forged by any website.
[33:12.490 --> 33:15.770]  Through this iframe sandbox script.
[33:17.510 --> 33:22.590]  This means that all trustable lore websites are not safe.
[33:22.590 --> 33:25.190]  It is also a trustable website.
[33:26.670 --> 33:30.850]  The yellow one is our POC.
[33:32.830 --> 33:37.550]  This kind of lore example has also caused a lot of security issues in history.
[33:37.630 --> 33:40.850]  For example, in 2016,
[33:40.850 --> 33:43.570]  Facebook Messenger was discovered.
[33:43.570 --> 33:45.830]  Because of this trustable lore,
[33:45.830 --> 33:48.170]  any user can read it.
[33:48.170 --> 33:54.450]  And any attacker can read Facebook Messenger's chat message.
[33:57.990 --> 33:59.590]  The third category is...
[33:59.850 --> 34:02.690]  Let's see what kind of problems the signal might bring.
[34:05.330 --> 34:09.550]  The signal in the course allows any desire.
[34:09.550 --> 34:11.030]  It looks very intuitive.
[34:11.030 --> 34:13.030]  But it allows any desire.
[34:13.030 --> 34:16.030]  It is too loose.
[34:16.490 --> 34:19.190]  The course has another rule.
[34:19.190 --> 34:22.050]  The signal can't be used with Cookies.
[34:22.050 --> 34:24.150]  It can't be used at the same time.
[34:24.830 --> 34:28.230]  This means that the signal can only be shared in public.
[34:28.230 --> 34:29.770]  It doesn't need authentic resources.
[34:29.770 --> 34:31.550]  If you want to bring Cookies to visit this resource,
[34:31.550 --> 34:33.170]  you can't use the signal.
[34:33.530 --> 34:35.810]  And all browsers follow this standard.
[34:35.810 --> 34:37.090]  As long as you match this configuration,
[34:37.090 --> 34:38.150]  it is considered unsafe.
[34:38.190 --> 34:41.870]  It will refuse to say that this configuration is a false configuration.
[34:42.550 --> 34:46.050]  In the actual website,
[34:46.050 --> 34:50.850]  we found that many websites didn't notice that this configuration is a false configuration.
[34:51.510 --> 34:54.090]  Including some big websites.
[34:54.650 --> 34:56.270]  For example, security.harvard.edu.
[34:56.270 --> 35:00.550]  It is not the security department.
[35:00.550 --> 35:03.550]  It is the information security department of Harvard.
[35:04.750 --> 35:06.630]  There is still no configuration.
[35:07.410 --> 35:09.290]  The problem is that there is no configuration team.
[35:13.670 --> 35:16.190]  What is more interesting is that
[35:16.190 --> 35:17.990]  we found that there is a framework.
[35:17.990 --> 35:20.790]  Because the configuration signal and true will be wrong,
[35:20.790 --> 35:22.830]  the framework will take the initiative to convert the signal and true
[35:23.910 --> 35:26.210]  into a reflection-friendly orange.
[35:26.210 --> 35:29.030]  The reflection-friendly orange we mentioned earlier is very dangerous.
[35:31.470 --> 35:35.410]  We tested 11 mainstream frameworks.
[35:35.410 --> 35:36.530]  We found that there are 8.
[35:36.610 --> 35:41.070]  If the user directly matches the signal and true in this configuration,
[35:41.070 --> 35:46.250]  it will take the initiative to reflect it into a reflection-friendly orange.
[35:48.110 --> 35:51.290]  The fourth problem is the security problem caused by the course and cache.
[36:00.110 --> 36:03.470]  For example, there is a resource server, c.com.
[36:03.470 --> 36:08.570]  It wants to share data with a.com and b.com at the same time.
[36:09.350 --> 36:14.530]  If the user first visits c.com via a.com,
[36:16.310 --> 36:18.570]  and then c.com returns and says,
[36:18.570 --> 36:21.030]  I allow a.com, you are in my list.
[36:23.250 --> 36:24.910]  Then the user...
[36:24.910 --> 36:28.430]  But this response will be delayed by the middle cache.
[36:28.870 --> 36:33.690]  It may be a browser cache or a transparent cache in the middle.
[36:36.960 --> 36:43.080]  So if b.com also wants to visit the resources of c.com,
[36:43.080 --> 36:44.860]  but it will be detected by this cache.
[36:46.360 --> 36:52.140]  Then the feedback is to allow a.com to save the content before.
[36:52.260 --> 36:55.660]  This a.com obviously does not match the b.com issued by the request.
[36:56.120 --> 36:59.080]  This leads to the failure of the b.com in the later visit.
[36:59.900 --> 37:04.340]  This leads to a failure of the function of the course.
[37:08.280 --> 37:10.060]  For this kind of situation,
[37:10.060 --> 37:14.780]  the ATP protocol provides the VeryHeader to solve this problem.
[37:14.780 --> 37:19.360]  When you set up the VeryOriginHeader in the response to guide the cache,
[37:19.360 --> 37:23.720]  you have to drag the origin into the cache key.
[37:23.960 --> 37:29.060]  Of course, we found that many websites,
[37:29.060 --> 37:32.780]  when developing anti-cache control strategies,
[37:32.780 --> 37:35.340]  did not match the VeryOriginHeader.
[37:41.640 --> 37:46.200]  Now we have found a bunch of mis-configuration problems.
[37:46.460 --> 37:49.500]  Let's take a look at the real website.
[37:49.500 --> 37:51.760]  What kind of security problems may there be on the real website?
[37:52.040 --> 37:54.080]  What will the security situation be like?
[37:54.860 --> 37:57.140]  We are going to do a measurement in four parts.
[37:57.800 --> 38:00.060]  First, we select the target.
[38:00.880 --> 38:08.140]  We select a website with 50,000 AlexTurps as our measurement target,
[38:08.140 --> 38:10.280]  because it is a highly influential website.
[38:11.320 --> 38:14.840]  Then we extract their domain name from the 50,000 websites.
[38:15.720 --> 38:18.140]  We extracted 90 million domain names.
[38:18.320 --> 38:21.800]  The data comes from the passive DNS data provided by 360 Internet Security Union.
[38:25.780 --> 38:32.300]  Then we dynamically detect the configuration of the course for each domain name.
[38:32.560 --> 38:35.840]  Why do we have to detect it dynamically, instead of scanning it directly?
[38:36.000 --> 38:39.940]  Mainly because the anti-cache control strategy of the course
[38:39.940 --> 38:43.400]  does not return to each response directly.
[38:43.420 --> 38:45.380]  Because it needs to be dynamically generated.
[38:45.660 --> 38:49.100]  Only if your OriginHeader hits its anti-cache control strategy,
[38:49.100 --> 38:49.940]  will it return.
[38:50.300 --> 38:51.780]  If you don't have an OriginHeader,
[38:51.780 --> 38:54.380]  or OriginHeader does not hit its anti-cache control strategy,
[38:54.380 --> 38:55.320]  it will not return.
[38:57.180 --> 38:59.880]  So we need to take the initiative to detect it.
[39:01.580 --> 39:05.120]  For example, here we are going to detect if the service end has the configuration
[39:06.120 --> 39:09.260]  to allow NOR to visit.
[39:09.260 --> 39:12.660]  We set the OriginNOR in the request,
[39:12.660 --> 39:14.640]  and then see if it returns the access control,
[39:14.640 --> 39:18.040]  along OriginNOR, such a value.
[39:20.340 --> 39:23.440]  The result of the test is that we found that 480,000 domain names
[39:23.440 --> 39:25.540]  are configured to the course.
[39:26.240 --> 39:29.270]  Basically, it covers every website of X50,000.
[39:32.220 --> 39:35.120]  Among them, 130,000 are configured to have a problem,
[39:35.120 --> 39:37.080]  which is about 27.5%.
[39:37.080 --> 39:42.820]  So this problem is widespread on the Internet.
[39:43.300 --> 39:44.040]  This kind of...
[39:44.920 --> 39:46.960]  Electro 50,000 is relatively safe.
[39:46.960 --> 39:50.160]  Not to mention other websites that are not on this list.
[39:53.260 --> 39:55.320]  So how to prevent this kind of loophole?
[39:56.360 --> 40:03.800]  We reported all the security problems we found to the relevant manufacturers.
[40:05.740 --> 40:07.280]  Some manufacturers have already fixed it,
[40:07.280 --> 40:08.200]  such as Sohu.
[40:08.200 --> 40:09.840]  Some are still being fixed.
[40:10.580 --> 40:14.300]  For such a problem, how to prevent it?
[40:14.440 --> 40:16.240]  This problem is divided into two aspects.
[40:16.240 --> 40:20.080]  One is the overloading of the course.
[40:20.160 --> 40:22.360]  The other is the problem of read configuration.
[40:22.800 --> 40:24.700]  For overloading,
[40:25.260 --> 40:27.360]  we reported to the Chrome browser,
[40:27.360 --> 40:28.180]  Firefox browser.
[40:28.180 --> 40:31.060]  They haven't released the fix yet,
[40:31.060 --> 40:33.240]  but one of the preventive measures they want to do is
[40:34.080 --> 40:39.960]  to prohibit external websites from visiting the internal network.
[40:40.100 --> 40:42.660]  That is, cross-network is not allowed.
[40:43.060 --> 40:45.020]  Use the browser as a jump board to visit the internal network.
[40:48.440 --> 40:51.140]  As for the problem of misconfiguration,
[40:51.140 --> 40:52.280]  we found that...
[40:52.800 --> 40:55.220]  Of course, we can blame the developers for not noticing it.
[40:55.220 --> 40:57.860]  Of course, the developers have to bear a lot of responsibility.
[40:57.940 --> 41:00.800]  Another big responsibility is that the course has a lot of
[41:03.020 --> 41:04.140]  weird cases,
[41:04.140 --> 41:05.280]  such as the case of Nord.
[41:06.300 --> 41:09.920]  Many websites do not clearly write this standard.
[41:10.140 --> 41:16.260]  Many website developers do not know there is such a weird case.
[41:16.260 --> 41:22.180]  So it's best to clarify all kinds of security risks in this standard.
[41:23.520 --> 41:26.260]  And what the website manager can do is
[41:28.780 --> 41:31.660]  check if your course configuration has this problem.
[41:31.780 --> 41:36.320]  We provide a source tool,
[41:36.320 --> 41:38.540]  which is the course scanner.
[41:39.860 --> 41:45.360]  You can use this to scan a website to see if it is safe.
[41:45.360 --> 41:47.700]  This is a screenshot.
[41:48.560 --> 41:52.580]  We scanned the top 100 websites,
[41:52.580 --> 41:54.520]  and we found a lot of misconfiguration.
[41:57.240 --> 42:00.360]  You are welcome to download and use this tool.
[42:00.780 --> 42:02.620]  Since I used this tool,
[42:04.940 --> 42:07.000]  I don't find bugs every day at work.
[42:07.000 --> 42:08.260]  There are too many bugs,
[42:08.260 --> 42:09.640]  because there are too many misconfigurations.
[42:09.640 --> 42:10.620]  I can't handle it.
[42:11.020 --> 42:12.820]  So you are welcome to use this tool.
[42:12.820 --> 42:17.920]  You can definitely find a lot of security issues.
[42:27.490 --> 42:29.870]  To sum up,
[42:32.830 --> 42:34.430]  there are three types of problems with the course.
[42:34.430 --> 42:39.770]  The first one is that it may cause security issues for the internal network
[42:39.770 --> 42:39.810]  due to its too lenient forwarding.
[42:39.810 --> 42:40.910]  This is not detailed,
[42:40.910 --> 42:44.330]  but it is a very important contribution to our work.
[42:44.330 --> 42:48.390]  Maybe we will talk about this specific security issue
[42:48.390 --> 42:49.410]  in the next session.
[42:49.410 --> 42:50.650]  The second type of problem is that
[42:50.650 --> 42:52.490]  the course brings new people's dependence
[42:53.770 --> 42:55.730]  and new people's security risks.
[42:55.730 --> 42:56.550]  The third type is that
[42:56.550 --> 42:59.070]  there are a lot of corollary cases in the course.
[43:00.670 --> 43:02.750]  There are a lot of misconfigurations
[43:02.750 --> 43:03.350]  in the actual website,
[43:03.950 --> 43:06.350]  which brings new security issues.
[43:07.030 --> 43:08.510]  This is my report.
[43:08.670 --> 43:09.350]  Thank you.
